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Abstract 

The  timing  behavior  of  a  real-time  system  depends  not  only  on  delays  due  to  process  syn¬ 
chronization,  but  also  on  resource  requirements  and  scheduling.  However,  most  real-time 
models  have  abstracted  out  resource-specific  details,  and  tlnls  assume  operating  environ- 
•  ments  such  as  maximum  parallelism  or  pure  interleaving.  This  paper  presents  a  real-time 
formalism  called  Commilnicating  Shared  Resources  (CSR).  CSR  consists  of  a  programming 
language  that  allows  the  explicit  expression  of  timing  constraints  and  resources,  and  a  com¬ 
putation  model  that  resolves  resource  contention  based  on  event  priority.  We  provide  a 
full  denotational  semantics  for  the  programming  language,  grounded  in  our  resource-based 
computation  model.  To  illustrate  CSR,  we  present  a  distributed  robot  system  consisting 
of  a  robot  arm  and  a  sensor. 


1  Introduction 

A.  IN  i  ■  I 

During  the  past  several  years  there  has  been  rapid  progress  in  the  development  of  formal 
s'efe^TO(?f767rF3l!??tift?'programfnin§,r£hguages.  Hd^eVter,  most  research  has  treated  language 
as  an  abstraction,  quite  isolated  from  any  vali6  operating  environment.  Thus,  often  unrealistic 
assumptions  are  made  about  a  formalism’s  underlying  computational  model.  Such  assumptions 
range  from  the  overtly  optimistic  (e.g.,  a  one-to-one  assignment  of  processes  to  processors) 
to  the  bleakly  pessimistic  (e.g.,  all  interleavings  of  process  executions  are  possible).  These 
assumptions  rarely  hold  in  practice,  and  using  them  to  reason  about  a  real-time  system's 
temporal  properties  can  often  lead  to  incorrect  conclusions. 

‘This  research  was  supported  in  part  by  ONR  N000014-89-J-1131. 
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It  is  now  understood  that  models  based  on  pure  interleaving  semantics  are  unsuitable  as 
real-time  formalisms.  Since  interleaving  concurrency  cannot  adequately  portray  simultaneous 
actions,  it  fails  to  permit  reasoning  about  a  distributed  system’s  temporal  properties.  Several 
real-time  process  algebras  have  addressed  this  issue,  among  which  are  ECP  [5],  TCSP  [16]  and 
Timed  Acceptances  [19];  each  of  the  semantics  underlying  these  formalisms  can  successfully 
portray  “true”  concurrency.  However  they  each  suffer  from  the  same  defect,  in  that  they 
place  no  resource  constraints  on  their  underlying  computational  models.  Further,  they. each 
permit  n-way  event  synchronization  between  processes  which,  while  algebraically  pleasing, 
has  an  unfortunate  consequence:  processes  may  delay  indefinitely,  waiting  for  communicating 
partners  that  simply  do  not  exist.  For  example,  assume  that  a  system  of  two  processes,  Pi  and 
P2,  exclusively  share  some  event  a.  Even  if  they  successfully  synchronize  on  a,  there  still  exists 
a  possibility  that  they  may  use  a  to  synchronize  with  an  elusive  P3  -  although  the  system 
consists  only  of  Pi  and  P2.  In  [16]  the  hiding  operator  can  force  the  desired  synchronization. 
Thus  one  may  trade  observational  information  for  correct  temporal  properties,  which  seems  a 
fairly  high  price  to  pay. 

Recently  there  has  been  increasing  interest  in  the  maximum  parallelism  view  of  concurrency, 
first  advanced  in  [17].  In  [11]  it  was  coupled  with  a  linear-history  semantics  [3],  and  used  to 
model  many  temporal  properties  of  Ada  [18].  The  maximum  parallelism  model  circumvents  the 
problem  of  unnecessary  idling;  if  two  processes  are  ready  to  communicate,  the  communication 
cannot  be  arbitrarily  delayed.  To  accomplish  this,  event  synchronization  between  processes  is 
limited  to  one  sender,  and  one  receiver.  Lately, ’variants  of  this  semantics  have  been  used  to 
model  a  real-time  version  of  occam  [7],  Statecharts  [8]  and  a  design  language  for  distributed, 
reactive  systems  [13]. 

The  main  defect  in  “pure”  maximum  parallelism  is  that  it  assumes  unlimited  computational 
resources:  To  enforce  the  constraint  of  “no  unnecessary  idling,”  each  process  must  be  mapped 
to  its  own,  dedicated  processor.  Thus  the  sharing  of  resources,  with  all  its  attendant  scheduling 
issues,  can  neither  be  specified  nor  analyzed.  This  is  unfortunate,  since  most  real-time  systems 
do,  in  fact,  share  their  resources  among  many  processes  [10]. 

To  address  this  problem,  we  have  developed  a  real-time  formalism  called  Communicating 
Shared^ResbUrces ,  or  CSR.  CSR’s  underlying  computational  model  is  resource- based,  where  a. 
nosowa^e^^^frcft.-gf^essor,  an.E&jt&net  link,  or,?^yr*pther  constituent  device  in  a  real-time 
system.  At  any  point  in  time,  each  resource  jia.s  the^capacity  to  execute  only  a  single  action. 
However,  a  resource  may  host  a  set  of  many  processes,  and  at  every  instant,  any  number 
of  these  processes  may  compete  for  its  availability.  “True”  concurrency  may  take  place  only 
between  resources;  on  a  single  resource,  the  actions  of  m  iltiple  processes  must  be  interleaved. 
To  arbitrate  between  competing  events,  CSR  employs  a  priority-ordering  among  them.  This 
priority  scheme  forms  the  heart  of  our  semantics. 

Quite  recently  there  has  been  some  exploration  of  priorities  in  both  untimed  and  real-time 
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formalisms  (see  [2,  9,  13]).  However,  these  studies  have  treated  a  limited  subset  of  the  problem 
-  that  of  the  priority-based  guarded  command,  such  as  Occam's  PRI  ALT  [15].  CSR’s  priority 
semantics  can  successfully  give  meaning  to  this  construct.  However,  CSR  addresses  the  much 
more  general  issue  of  resource-sharing  by  multiple  processes,  processes  that  may  contain  many 
such  prioritized  guarded  commands,  and  that,  over  time,  may  continuously  have  their  priorities 
altered. 

This  paper  is  organized  as  follows:  Section  2  gives  an  overview  of  CSR,  with  both  its  syntax 
and  its  informal  semantics.  In  section  3  we  extend  the  basic  CSR  formalism  by  supplying 
higher-level  communication  primitives.  Section  4  presents  an  example  of  a  real-time,  robotics 
system,  modeled  with  the  extended  CSR  language.  In  section  5  we  provide  the  mathematical 
semantics  for  our  language.  Finally,  in  section  6,  we  state  our  future  objectives. 


2  Overview  of  CSR 


The  CSR  language  provides  the  foundation  for  our  real-time  specification  method,  and  all 
of  our  higher-level  constructs  are  derived  from  it.  In  several  ways  it  syntactically  resembles 
the  variants  of  real-time  CSP  found  in  [7]  and  [11].  Yet  it  includes  many  additional  features 
that  take  full  advantage  of  our  priority  semantics.  Furthermore,  it  has  the  capacity  to  specify 
many  constructs  quite  common  in  real-time  systems,  such  as  timeouts,  periodic  processes,  and 
exception-handling. 

•  . 

2.1  Events 


Our  basic  unit  of  computation  is  the  event,  which  we  use  to  model  both  interprocess  commu¬ 
nication  as  well  as  local  process  execution.  All  of  our  events  are  drawn  from  the  finite  event 
alphabet  E.  Here  we  use  the  following  conventions: 

•  The  letters  a,  b  and  c  range  over  E. 


•  The  letters  A,  B  and  C  range  over  ^(S). 

•  'file  *6  reek  letters  A  and  P  range  over  V(V(E)). 

Wlieif^xecilfl^f^ff  ?vent  consume^exactly  one  tiirfe  'iinit.  However,  this  dsesjiot  imply  that 
all  actions  require  exactly  the  same  amount  of  time,  On  the  contrary,  the  event  should  only  be  { 
considered  a  common  infinitesimal  unit,  a  building-block  with  which  more  complex  functions 
are  constructed.  1 


□ 

a 


.->n_ 


2.1.1  Communication  and  Computation 


In  CSR  all  communication  between  processes  is  strictly  one-to-ore,  and  performed  bv  svn- 
...  '  •  ty  Cocloa 

chronizmg  on  common  events.  So  if  a  represents  such  a  synch ronizjpg-ei^nt,  there  is  a  single  Q^'/Qr~~ 

id*.  ,  ipooial 
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process  P  that  may  utilize  a  to  denote  a  “write”  action,  and  a  single  process  Q  that  may  use  a 
to  denote  a  “read.”  Syntactically,  P  would  contain  the  “a!”  statement,  while  Q  would  contain 
the  “a?”  statement.  When  both  processes  agree  to  communicate,  they  both  simultaneously 
execute  the  a  event.  At  that  point  we  say  the  event  is  resolved. 

As  we  have  stated,  events  may  also  be  used  to  explicitly  represent  local  computation  within 
a  process;  that  is,  any  action  that  requires  possession  of  the  processor’s  resources.  Syntactically, 
one  unit  of  a  local  computation  is  simply  denoted  by  an  event  name,  such  as  “a.”  Semantically 
it  is  treated  as  a  communication  event  that  has  implicitly  been  resolved. 

2.1.2  Event  Priority 

Both  of  the  two  processes  that  synchronize  on  an  event  have  their  own  priorities  associated 
with  it.  In  other  words,  each  communicating  event  has  two  priorities,  one  for  the  “reader”  and 
the  the  other  for  the  “writer.”  Two  functions,  PRI{  E  £  — ►  N  and  PRI0  €  S  —  N  represent 
the  respective  priority  mappings.  If  a  process  uses  event  a  to  model  a  read  action,  the  priority 
of  that  action  is  PRR(a).  Similarly,  if  a  process  uses  a  to  model  a  write,  the  associated  priority 
is  PRI0(a).  On  the  other  hand,  if  the  event  a  is  employed  to  represent  a  computation  unit, 
the  function  PR1  (a)  yields  the  priority  of  a. 


2.2  The  Syntax  of  CSR 

The  following  is  a  complete  grammar  for.  the.  CSR  language: 


(system)  ::= 
(resource) 
(process)  ::= 
(stmt)  ::= 

.4u.?<u>  ::= 

(guard)  ::= 
(within-s) 
(interrupts)  ::= 
(loop_s) 
(every-s)  ::= 


(resource)  |  (system)  ]|  (system) 

{(process)} 

(stmt)  |  (process)  &  (process) 

waitt  |  skip  \al  \a\\  exec  (a,  m,n)  |  (stmt)  ;  (stmt)  |  (guard_s)  | 
(within-s)  |  (interrupts)  |  (loop_s)  |  (every-s) 

[(guard)  — +  (stmt)D  . . .  □  (guard)  — *•  (stmt) A  wait  t—  (stmt)]  | 

[(guard)  -^Jstmt)Q  , . .  □  (^uard)  (stmt)] 

a\a1\a\  F  ,  ~=~'' 

within  t  do  (stmt)  when  t  — *  (stmt)  od 

interrupt  a  do  (stmt)  when  a7  —  (stmt)  od 

loop  do  (stmt)  od 

every  t  do  (stmt)  od 
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2.3  Informal  Semantics 

We  now  provide  a  brief,  informal  semantics  for  these  constructs.  In  section  5.9  we  expand  on 
the  ideas  presented  here,  and  we  also  present  the  formal  semantics  for  the  language. 

The  wait  statement  specifies  a  pure  delay  for  t  time  units,  while  skip  is  syntactic  sugar  for 
the  construct  wait  1.  The  read  statement,  a?,  waits  indefinitely  for  a  communicating  process 
to  execute  the  corresponding  write  statement,  or  a!.  The  exec(a,m,n)  construct  denotes  local 
computation  -  the  event  a  may  be  executed  for  a  minimum  of  m,  and  a.  maximum  of  n  time 
units.  Sequential  composition  is  similar  to  that  in  the  traditional,  untimed  CSP. 

The  guarded  statement  is  a  prioritized  variant  of  that  presented  in  [11].  In  the  version 
without  a  timeout,  all  of  the  communication  guards  delay  indefinitely,  waiting  to  be  matched 
with  their  communicating  partners.  As  soon  as  the  first  match  is  made,  the  guard  with  the 
highest  priority  takes  precedence,  and  the  statement  associated  with  it  is  executed.  However, 
note  that  we  also  allow  local  events  as  guards,  and  if  one  of  these  is  included  no  delay  is 
necessary.  Thus  the  priority  arbitration  occurs  immediately.  And,  if  a  timeout  guard,  wait  t, 
is  included  in  the  statement,  communication  is  only  attempted  for  up  to  t  time  units,  after 
which  the  timeout  statement  is  executed. 

The  interrupt  operator  functions  in  the  following  manner:  To  be  interrupted,  the  main 
body  must  currently  be  executing  an  event  that  has  lower  priority  than  the  interrupting  event. 
If  this  is  the  case,  control  transfers  immediately  to  the  interrupt  handler.  The  within  statement 
specific  that  its  body  must  execute  within  a  specified  time  limit.  If  it  fails  to  do  so,  an  exception 
statement  is  executed.  Note  that  this  facility  provides  for  the  specification  of  nested  temporal 
scopes  [12],  as  within  stater  ents  may  themselves  be  nested.  The  loop  statement  specifies 
general,  unguarded  recursion,  while  the  every  construct  denotes  a  statement  that  executes 
periodically. 

There  are  two  types  of  concurrent  operators:  Interleaving  is  denoted  by  the  symbol, 
while  true  parallelism  is  represented  by  the  “||”  symbol.  True  parallelism  can  take  place  only 
between  different  resources,  while  interleaved  processes  execute  on  the  same  resource.  In  fact, 
all  expansions  of  the  (resource)  nonterminal  are  required  to  be  executed  on  a  single  resource 
(or  processor).  This  is  guaranteed  by  the  restrictions  inherent  in  the  grammar,  and  assumed 
in. the  construction  of  the  formal  semantics. 

A<*rt,Tt*cm}rd'cr:;;?t;f£‘r,Cir,  • 1  ,/nrir:  1  . -Tv 

lo  a  certain  extent  Cod,  provides  not  only  a  real-time  programming  paradigm,  but  also  a 
configuration  language.  Unlike  other  CSP-inlluenced'Tanguages,  the  structure  of  our  language 
mandates  chat  process-to-resource  mapping  be  performed.  Processes  are  allocated  to  a  single 
resource  by  simply  expanding  the  (resource)  nonterminal.  When  no  additional  process  is  to 
be  added,  the  resource  is  closed.  This  is  done  by  using  the  close  operator,  or  “{  .  }.”  And 
after  a  resource  is  closed,  no  other  processes  may  compete  for  its  allocation.  At  '  ,iat  time  it  is 
considered  a  resource,  and  can  only  be  combined  in  parallel  with  other  resources  in  the  system. 

There  are  several  significant  restrictions  made  on  the  events  used  both  within  and  between 
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resources.  First,  if  an  event  a  represents  a  synchronizing  action,  a  single  resource  may  not  use  a 
for  both  reading  and  writing.  Recall  that  communication  is  one-to-one,  between  resources.  If  a 
resource  uses  both  functions  of  the  event  it  may  communicate  with  itself.  And  since  all  actions 
on  a  single  resource  are  purely  interleaved,  it  is  impossible  for  the  read  and  write  actions  to 
occur  simultaneously.  Thus  if  interleaved  processes  need  to  communicate  with  each  other,  they 
must  utilize  intermediate  resources  such  as  memory,  communication  media  and  the  like. 

Next,  two  different  resources  may  not  model  a  common  function  using  the  same  event.  For 
example,  given  an  event  a,  two  different  resources  cannot  execute  the  “«!”  statement.  This 
would  also  violate  our  restriction  that  all  communication  must  be  one-to-one.  If  many-to-one 
communication  protocols  are  desired  (as  in  Ada  [18]),  they  must  explicitly  be  modeled  through 
guarded  statements. 

One  final  restriction  is  that  no  two  resources  may  share  a  single  local  event.  Again,  a  local 
event  is  considered  a  unique  unit  from  a  particular  resource.  Thus,  sharing  it  would  violate 
the  very  resource  constraints  that  we  are  attempting  to  model. 

To  some  readers,  many  of  these  restrictions  may  appear  overly  harsh.  Superficially  at  least, 
it  seems  that  two  interleaved  processes  should  be  able  to  directly  communicate  with  each  other. 
Yet  cost  must  be  assessed  where  cost  is  due,  and  permitting  two  such  simultaneous  actions 
would,  lead  to  improper  conclusions  about  the  system.  At  the  very  least  it  should  require  one 
time  unit  for  the  sender  to  send,  and  another  unit  for  the  receiver  to  receive.  In  most  operating 
systems  this  type  of  communication  is  performed  by  mailboxes  or  signals.  Such  mechanisms 
require  time  to  execute.  ' 

It  should  be  noted  that  our  grammar  excludes  some  of  the  constfucts  permitted  by  many 
other  concurrent  languages.  For  example  we  do  not  implicitly  allow  a  simple  fork-join  program, 
such  as 

Q  =  Pi;(P2||P3);P4 


In  a  typical  language  this  program  can  be  written  without  regard  to  such  details  as  resource 
allocation,  control  between  processors  and  the  like.  Yet  if  P2  and  P3  are  to  be  on  separate 
resources,  we  cannot  assume  that  they  both  begin  exactly  when  Pi  ends.  It  is  even  more 
unlikely  cthat  Pj  will  start  exactly  when  either  P2  or  P3  ends,  whichever  is  slowest.  Indeed, 
at  both  the  fork  and  join  transitions  there  is  always  “hidden”  resource  consumption,  such  as 
operating  sys^em^overliead.  To  analyze  the  correct  temporal  behavior  of  such  a  system,  this 
type  of  resource  consumption  must  be  explicitly  modeled. 


3  Extended  CSR 

The  “pure”  CSR  language  described  above  captures  priority- based  interleaving  subject  to  re¬ 
source  availability,  and  pure  parallelism  subject  to  event  synchronization.  The  language  is  quite 
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powerful,  and  can  successfully  model  a  real-time  system  consisting  of  shared  resources.  How¬ 
ever,  the  modeling  of  communication  through  instantaneous,  synchronizing  events  becomes  too 
cumbersome  a  task  when  describing  large,  real-time  applications.  For  example,  two  processes 
sharing  a  single  resource  cannot  directly  synchronize  with  each  other;  they  must  communicate 
through  an  intermediate  resource,  such  as  memory. 

In  this  section,  we  augment  the  basic  language  with  the  notion  of  channels  (or  commu¬ 
nication  ports),  and  provide  asynchronous  send  and  receive  operations  on  them.  While  the 
communication  media  must  still  be  explicitly  modeled,  we  keep  this  layer  transparent  to  the 
application  processes.  The  processes  may  communicate  with  each  other  in  a  homogeneous 
manner,  regardless  of  the  various  resources  they  use. 

The  major  extension  to  the  language  is  in  the  expanded  definition  of  the  (process)  nonter¬ 
minal: 

(process)  ::=  (process-header) (stmt)  | 

(process)  &  (process) 

(process-header^  process  (ident) 

[  input  (channel-defs)  ] 

[  output  (channel-defs)  ] 

[  local  (channel-defs)  ] 

•  (cha,nnel-defs)  ::=•  (ident)  ((priority))  [,  (channel-defs)  ] 

Each  user  process  declares  the  communication  channels  that  it  is  going  to  use  for  messages, 
along  with  their  associated  priorities:  input  channels  are  for  receiving  messages  and  output 
channels  are  for  sending  messages.  Local  computation  events  are  declared  in  a  similar  manner, 
although  they  retain  their  previous  flavor. 

Two  processes  asynchronously  communicate  on  channel  c  using  two  primitives,  a_send(c) 
and  a_recv(c).  A  process  that  invokes  a_send(c)  may  execute  its  next  statement  as  soon  as 
the  communication  medium  accepts  a  message  on  channel  c.  A  process  that  invokes  a_r ecv(c) 
is  delayed  until  there  is  a  message  present  on  channel  c.  These  primitives  are  expanded  from 
the  ^stmt)  nonterminal,  and  can  be  used  wherever  a  statement  may  appear.  In  fact,  they 
^ransfTte^mfJTsffnfil? ^ad  and  write'sia'tements,  as'^e’fehall  show  below.  -  • 

In  the  following  example,  process  P\  receives  messages 'from  P-2  on  channel  c.  Also,  P\ 
reserves  the  event  a  for  local  computation,  while  P2  uses  a  local  event  b. 

process  P\  process  P2 

input  c(10)  output  c(l) 

local  a(l)  local  6(2) 

process  body  process  body 
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Figure  1:  Translation  of  channels  to  events 

The  translation  from  channels  to  events  is  quite  straightforward.  In  Pi,  the  channel  c  is  simply 
translated  to  the  event  c.r,  while  in  P2,  c  is  mapped  to  the  event  c.s  (see  Figure  1).  The 
headers  of  the  two  processes  establish  the  following  event  priorities: 

PRIi(c.r)  =  10  PRh(a)  =  1  PRI0(c.s )  =  1  PRIt(b)  =  2 

As  for  the  translation  of  the  communication  primitives,  any  appearance  of  a_recv(c)  in  P\  is 
simply  replanced  by  the  statement  “c.r?”.  Similarly,  the  a_send(c)  primitive  in  Pi  is  replaced 
by  “c.s?”. 

It  is  the  responsibility  of  the  communication  medium  to  synchronize  with  c.r  and  c.s.  in  a 
manner  such  that  the  asynchronous  protocol  is  maintained.  This  underlying  medium  may  be 
•  as  simple  as  an  interrupt  controller,  or  as  complex  as  a  wide-area  network.  The  communication 
protocol  is  highly  application-dependent,  and  must  be  modeled  separately  for  each  real-time 
system. 


4  An  Example:  Modeling  a  Distributed  Robot  System 

Consider  a  robot  system  with  a  tactile  sensor.  The  purpose  of  the  system  is  to  move  the  robot 
arm  as  determined  by  the  controller  until  the  arm  touches  an  object.  This  distributed  robot 
systemVdhsists  of  processors,  a  robot  arm,  a  tactile  sensor  and  a  communication  link.  There 
Ate-  ftmr>ip#oi>i»iitot:;».^>ntrolleri  a  r»bot,  arm  drivers  rpbot  and  a  tactile  sensor. 

F 

4.1  Robot  and  Sensor  Processes 

Figure  2  shows  communication  dependencies  between  the  four  processes.  There  are  six  commu¬ 
nication  channels,  two  of  which,  stopped  and  touched ,  carry  interrupts.  The  controller  process 
sends  the  next-p  to  the  robot  arm  driver.  The  robot  arm  driver  interrupts  the  controller  process 
when  the  arm  has  stopped  through  the  stopped  channel.  Similarly,  the  sensor  process  sends  a 
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Figure  2:  Communication  Structure  of  the  Distributed  Robot  System 

touched  interrupt  to  the  robot  arm  driver  when  an  object  has  been  touched.  The  robot  arm 

driver  moves  the  arm  by  sending  r-move,  or  stops  it  by  sending  r-stop. 

Figure  3  details  each  process,  written  in  extended  CSR.  Every  2S  time  units,  the  controller 

process  determines  a  new  arm  position,  which  takes  between  10  and  14  time  units,  and  sends 

it  to  the  arm  driver  process.  This  procedure  continues  until  the  robot  arm  driver  notifies  the 

controller  process  that  the  arm  has  stopped.  Based  ’on  the  current  arm  coordinates  and  the 

» 

new  position  received  from’  the  controller,  the  robot  arm  driver  computes  the  joint  angles. 
This  computation  requires  between  5  and  8  time  units,  after  which  the  robot  arm  is  moved.  A 
sensor  is  attached  to  the  arm,  and  every  10  time  units  the  sensor  process  determines  whether 
an  object  has  been  touched.  If  such  a  determination  is  made,  the  sensor  process  informs  the 
robot  arm  driver,  which  must  stop  the  robot  as  soon  as  possible.  Thereafter,  the  arm  driver 
process  notifies  the  controller  process.  For  simplicity,  the  sensor  process  is  modeled  as  choosing 
nondeterministically  between  skip  and  a_send {touched). 

4.2  A^omplete  Robot  System 

^lfi’c^'YK^fn'Bhf^efP^'ior  of  the  rdBb'f-’system  depbhd's  not  only  on  synchronization  between 
processes  but  also  on  resource  availability,  it  is^hecessary  to  kn’ow  which  processes  are  competing 
for  the  same  resource.  Suppose  that  the  robot  system  is  to  run  on  three  processors  connected 
by  a  shared  communication  link  such  as  an  Ethernet.  The  controller  and  robot  arm  processes 
are  assigned  on  one  processor  and  the  robot  and  sensor  processes  are  their  on  own  processors. 
Thus,  channels  nexLp  and  stopped  are  for  local  communication,  whereas  the  other  channels 
are  for  non-local  communication.  Figure  4  shows  the  complete  robot  system  written  in  CSR 
using  the  translations  described  in  Section  3.  For  example,  channel  nexLp  is  moc  eled  using 
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process  Controller 
output  next.p(l) 
input  stopped(2) 

local  c(l)  /*  compute  next  position  */ 
interrupt  on  stopped  do 

every  28  do  exec(c,10,14);  a_send(next_p)  od 
when  a_recv(stopped)  — *  skip  /*  task  completed  */ 
od 

process  RobotArm 

input  next,p(2),  touched(3) 
output  r_move(2),  r_stop(2),  stopped(2) 
local  a(2)  /*  compute  joint  angles  */ 
interrupt  on  touched  do 

loop  do  a_recv(next.p);  exec(a,5,8);  a_send(r_move)  od 

when  a_recv(touched)  -*•  exec(a,5,8);  a_send(r_stop);  a_send(stopped) 

*  * 
od 

process  Robot 

input  r_move(l),  r_stop(2) 
loop 

[  a-recv(r-move)  -*  skip  □  a_recv(r_stop)  -*•  skip  ] 
od 

process  Sensor 
A  ^output  touched(2) 

F 

every  10  do 

[  sense  — <•  skip  O  sense  — ►  a-send(touched)  ] 
od 


Figure  3:  Distributed  Robot  System  Written  in  the  Extended  CSR 


May  7,  1989 


11 


System  = 
Nodei  = 
Node2  = 
Node3  = 
LCS  = 
Network  = 
Controller  = 


Robot  Arm  = 


Robot  = 
Sensor  = 


Nodei  ||  Node2  ||  Nodes  |j  Network 
{  Controller  &  RobotArm  }  ||  LCS 
{  Sensor  } 

{  Robot  } 

{  next-p.s?;  next.p.r!  ||  stopped.s?;  stopped.r?  } 

{  [  touched.s?  — ►  touched.r!  □  r_move.s?  — >•  r_move.r!  □  r_stop.s? 
interrupt  on  stopped.r  do 

every  28  do  exec(c,10,14);  next.p.s!  od 
when  stopped.r?  — ►  skip 
od 

interrupt  on  touched.r  do 

loop  do  next.p.r?;  exec(a,5,8);  r_move.s!  od 
when  touched.r?  — >  exec(a,5,8);  r_stop.s!;  stopped.s! 

od 

loop  [  r_move.r?  — ►  skip  □  rjstop.r?  -»•  skip  ]  od 
every  10  do  [  sense  -*  skip  □  sense  — »  touched.s!  ]  od 


r-stop.s!]  } 


Figure  4:  Complete  Robot  System  Written  in  CSR 


two  events,  nexLp.s  and  it  next.p.r.  Processes  LCS  and  Network  provide  local  communications 
within  Nodei  and  non-local  communications.  Nodes  1,  2  and  3  are  closed  to  form  resources 
since  no  additional  processes  are  going  to  be  assigned  to  them.  We  note  that  the  closing  of 
the  Network  process  does  not  change  its  meaning,  since  it  does  not  contain  any  local  events. 


X  c*. »  •  » 

5  A  Denotational  Semantics  for  CSR 

»  •  *  »*w7r\.  r  ,T> 

The  semantics  of  our  language  is  based,  in  ilarge  pjyt,  on  >  the  linear- history  paradigm  first 
presented  in  [3].  Updated  to  model  a  real-time  variant  of  CSP  in  [11],  it  was  further  revised 
and  provided  with  a  corresponding  operational  semantics  in  [7].  All  three  of  these  models  have 
contributed  to  the  formulation  of  our  semantics. 

The  two  abovementioned  real-time  models  subscribed  to  the  “maximum  parallelism"  view 
of  concurrency,  which  was  presented  in  [17].  Briefly,  maximum  parallelism  implies  that  within 
any  given  process,  delay  is  kept  to  a  minimum.  Or,  at  any  given  time  instant,  if  a  process  is  able 
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to  communicate  whenever  its  partner  is  ready,  it  will  communicate.  Thus  “pure”  maximum 
parallelism  implies  that  the  computational  resources  are  unlimited,  or  at  least  every  process 
is  mapped  to  its  own  processor.  There  is  no  interleaving  per  $e  -  only  the  guarded  command 
can  model  competition  for  resources. 

Furthermore,  the  “pure”  maximum  parallelism  implies  that  a  static,  bi-level  priority  scheme 
underlies  the  computational  model:  competition  between  idling  and  execution  is  always  re¬ 
solved  in  favor  of  the  latter.  Thus  “ties”  between  simultaneous  events  are  always  arbitrated 
nondeterministically.  For  example,  consider  the  system  S  —  where 

Ri  =  {[a?  -+&?□&?-+  a?]}  R2  =  {a!}  R3  =  {6!} 

Under  maximum  parallelism  without  priorities,  we  would  reason  that  either  event  a  is  com¬ 
municated  first,  and  then  6;  or,  b  is  communicated  first,  and  then  a.  The  decision  between 
these  alternatives  would  be  “resolved”  nondeterministically.  With  the  use  of  priorities,  our 
language  allows  us  eliminate  this  nondeterminism  if  desired:  thus,  if  PRT,(a)  >  PRI,(b),  the 
first  alternative  would  always  hold. 

5.1  States 

As  in  [11,  7],  thv  execution  of  a  process  is  represented  by  a  collection  of  (state,  history)  pairs. 
The  state  component  is  used  merely  to  depict  whether  a  computation  has  finished.  The 
two- valued  state  domain  is  denoted  S  =  {-L,T},  where  1  is  associated  with  an  incomplete 
computation,  and  T  denotes  that  a  computation  is  complete/  Thus  the  state  T  corresponds  to 
the  y/  element  in  most  trace  and  failure-based  models  [1,  5,  6,  16].  We  let  the  symbol  a  range 
over  S. 

5.2  Histories 

A  history  records  a  program’s  behavior  over  a  certain  period  of  time.  For  example,  if  the 
history  has  a  length  of  i  elements,  the  recorded  period  of  activity  is  i  time  units.  The  /- th 
element  represents  a  possible  activity  at  time  i. 

7o jfofhrtglf j.^aft^istory  isicajjft^an  assumption; record,  which  is  pair  (A,  A)  6  ^(S)  x 
V{'P('£,)).  Since  the  semantics  captures  true  concurrency,  at  qvery  time  unit'fhere  may  be  a  set 
of  events  that  executes.  If  an  assumption  record  appears  as  the  i-th  element  in  the  history,  the 
events  in  the  A  component  may  execute  at  time  i.  The  A  component  contains  other  sets  of 
events  that  also  may  execute  at  time  i;  however,  these  sets  all  have  an  equal  or  higher  priority 
than  that  of  A.  The  parallel  operator  ensures  that  if  an  A'  G  A  can  synchronize  with  its 
communicating  events,  and  if  the  priority  of  A'  is  higher  than  that  of  A,  the  set  A  will  not  be 
executed. 
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For  example,  examine  the  R\  fragment  in  section  5,  with  PRIfia)  >  PRIi(b).  There  are 
three  assumption  records  that  describe  the  possible  behaviors  at  the  first  time  unit: 

1.  (0,{{a>,{6}»  2.  ({6},  {{«}})  3.  «a},0) 

Record  1  shows  the  possibility  of  neither  a  nor  b  being  communicated  at  time  1,  and  thus,  the 
processor  may  idle.  However  it  also  shows  that  if  either  event  is  communicated  the  record  will 
be  deleted,  as  both  events  have  a  higher  priority  than  idling.  Record  2  shows  that  the  event  b 
may  be  communicated,  but  it  also  shows  that  competition  between  b  and  a  is  resolved  in  favor 
of  a.  Thus  if  a  “tie”  between  a  and  b  occurs,  this  record  is  deleted.  Record  3  shows  that  the 
event  a  may  be  communicated  at  time  1,  and  also  that  it  “wins”  competitions  for  its  processor. 

We  let  the  letters  r,  s  and  t  range  over  assumption  records.  We  define  two  selectors  on 
assumption  records.  Letting  r  =  (A,  A)  we  define  /i(r)  =  A  and  f2 (r)  =  A. 

As  we  have  stated,  the  information  captured  in  each  assumption  record  is  valid  for  one 
time  unit.  A  real-time  behavior  of  a  program  is  captured  by  a  history,  or  a  sequence  of  these 
records.  Histories  are  denoted  by  the  domain  H  =  {r\r  £  P(E)  x V(V(E))}m .  We  let  the  letter 
h  range  over  the  domain  of  histories,  and  in  the  spirit  of  [7],  we  use  the  following  notation  for 
them: 

•  hi~h2  represents  the  concatenation  of  hi  and  h2. 

•  A  is  the  empty  history,  where  Xh  =  h'\  =  h. 

•  rn  is  the  history  formed  by  n  concatenations  of  the  record  r.. 

•  |/i|  is  the  length  of  the  history  h. 

•  h[i]  represents  the  i-th  record  of  the  history  h.  If  i  >  |/i|,  define  h[i]  to  be  (0,0).  For  any 
history  h,  /j[0]  =  A. 

•  h\  <  h2  iff  G  H ,  h  £  A .  (hi  ~h  =  /i2)* 

5.3  partial  Ordering,  Prefix  Closure  and  Fixed  Points 

W»  fopqfr  WE  doffiaiH-of  linear  histertes  as  SH  -  <$-£  and  we  let  the  letter  X  range  over  it. 
The  domain  forms  a  complete  partial  order,  first,  (_|_,  A)  is  the  least  element.  The  ordering  is 
formed  as  follows.  If  Xi  C  SH  and  X2  C  SH,  then  Xi  C  X2  iff  Xx  C  X2.  Thus,  least 
upper  bounds  of  chains  are  determined  by  taking  the  union  of  every  set. 

We  require  that  the  computations  of  every  program  are  prefix- closed,  which  ensures  that 
all  of  our  operators  are  well-defined.  That  is,  they  all  generate  a  least  fixed  point  set  of 
(state,  history)  pairs.  For  a  given  set  X  G  SH,  we  denote  the  prefix  closure  of  A'  as 


<X  =  X  U  {(±,  h')  [  3(cr,  h)  G  X.h!  <  h } 
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5.4  Sequential  Composition  of  Sets  in  SH 

Assume  that  a  statement  S\  can  generate  a  set  of  behaviors  Xi ,  and  S2  can  generate  a  set 
of  behaviors  X2,  with  both  X\  and  X2  in  SH.  We  often  wish  to  sequentially  compose  the 
behaviors  from  two  sets  such  as  these.  That  is,  if  an  element  of  -Yx  is  finished  we  may  append 
an  element  of  X2.  Formally,  the  sets  axe  composed  using  the  function  C  £  SH  X  SH  — ►  SH, 
where 

C(Xi,X2)  =  {(±th)\(±,h)eXij  U 

<{{(?, hx~h2)  |  (T ,h\)  £  Xi  A  3 h2  .  ( a,h2 )  £  Ar2} 

5.5  Semantic  Representation  of  Programs 

A  process  1  P  =  (res,  imp,  exp,  p,  traces)  is  defined  as  follows: 

1.  res  £  P(E),  the  set  of  events  have  been  resolved  in  the  process  P.  Whether  originally 
used  to  model  local  computation  or  synchronization,  these  events  are  now  resolved  and 
are  local  to  P. 

2.  imp  £  P(E),  the  set  of  events  that  are  imported,  i.e.,  those  on  which  P  may  exercise  as 
“read”  actions. 

3.  exp  £  P(E),  the  set  of  events  that  are  exported,  i.e.,  those  on  which  P  may  exercise  as 
“\vrite”  actions. 

4.  p  £  V( S)  x  P(E)  —>  BOOL,  the  priority  function  for  P.  For  two  sets  of  events  .4  and 
B,  if  the  predicate  p(A,B)  holds,  we  say  that  the  “priority  of  A  is  less  than  or  equal  to 
the  priority  of  BP 

5.  traces  £  SH,  the  set  of  potential  executions  of  the  process  P. 

For  convenience,  we  make  the  following  definitions: 

p(P)  =  res  i(P)  =  imp  e(P)  =  exp  tt(P)  =  p  r(P)  =  traces 

A.  %.\  L  I  I 

^p.a^ditign^ve^cc^ionally  refer  tojhe  alphabet  of  a  process,  or  a(P),  as  its  complete  set  of 
observable,  events.  That  is,  the  alphabet  of  a  process  is  the  union  of  its  resolved,  imported  and 
exported  events:  a(P)  =  p(P)  U  i(P)  U  e(P).  J" 

'Here,  unless  ambiguous,  we  call  the  semantic  representations  of  all  program  fragments  processes.  We  use 
this  terminology  whether  the  syntax  of  the  fragment  is  a  statement,  process,  resource  or  system,  as  defined  by 
the  grammar. 
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5.6  Event  Consistency 

In  section  2.3  we  discussed  some  constraints  placed  on  the  events  in  a  program’s  substructures; 
now  we  can  treat  them  formally.  Assume  that  Pi,P2,  ...,Pn  are  processes  being  combined 
to  run  on  the  same  resource;  that  is,  their  syntax  was  expanded  from  a  single  (resource) 
nonterminal.  The  following  constraints  must  hold: 

Consistent &  =  ViVj 

i(Pi)  n  e(Pj)  =  0  A  e(Pi)  n  i(Pj)  =  0  A  (1) 

(e(Pi)  U  i(Pi))  n  p(Pj)  =  0  A  (e(Pj)  U  t(Pj))  n  p(Pi)  =  0  (2) 

Line  (1)  enforces  that  no  two  processes,  running  on  the  same  processor,  can  instantaneously 
communicate  with  each  other.  Since  the  two  processes  have  their  executions  interleaved,  such 
behavior  would  be  impossible.  Line  (2)  enforces  that  local  computation  and  communication 
cannot  be  modeled  by  the  same  event.  Local  computation  requires  no  synchronization  with 
external  resources,  while  communication  does. 

Now  assume  that  Pi  and  P2  are  subsystems  consisting  of  closed  resources,  to  be  combined 
by  the  “||”  operator.  We  insist  that  the  following  constraints  must  hold: 

Consistent^  =  a(Pi)  D  a(P2)  =  0  A  e(Pi)fl  e(P2)  =  0  A  (1) 

p(Pi)np(P2)  =  0  A'  (2)  . 

■(l(Pi)  U  e(Pi))  (1  p(P2)  =  0  A  (a(P2)  U  e(P2))  n  p{Pi)  =  0  (3) 

Line  (1)  enforces  that  communication  between  resources  is  strictly  one-to-one,  with  a  single 
receiver  and  a  single  sender.  Line  (2)  mandates  that  isolated  resources  are  not  shared:  the 
local  units  of  computation  from  each  are  private.  Line  (3)  enforces  that  a  single  event  cannot 
model  both  local  computation  and  communication. 

If  the  program  fragments  to  be  combined  satisfy  such  constraints,  we  call  them  consistent. 
To  avoid  redundancy  in  our  operator  definitions,  we  assume  that  all  fragments  combined  are, 
indeed,  consistent. 

1  vv  -  1  * 

S.^T^elinTng^life^Priority  Functions  *' >  "  - 

F  u. .  » 

We  use  two  functions  to  define  the  priority  predicates  for  our  combinators.  One  is  used  for 
creating  processes  that  execute  on  a  single  resource,  while  the  other  is  employed  strictly  in 
the  definition  of  parallel  composition.  Let  Pi,P2,...  ,P„  be  a  group  of  processes,  all  of  which 
are  to  run  on  the  same  resource.  We  assume  that  these  processes  are  consistent,  as  defined  in 
the  previous  section.  If  we  let  res  =  IJ-Lj  p(P,),  imp  =  U”=1  t(P,),  and  exp  =  U”  e(P,),  then 
Compo$eb{res,imp,exp )  completely  defines  the  priority  function  for  this  group  of  processes, 
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where: 


VA  C  EVP  C  E,  Compose^, i,  e)(A,B)  =  P&(r,t,e)(A)  <  P&(r,i,  e)(B), 


where 


P&(r,i,e)(C) 


'  PRIi(a)  if  C  n  r  =  {a} 
PRIi(a )  if  C  n  i  =  {a} 
PRI0(a)  if  C  n  e  =  {a} 
0  otherwise 


The  definition  requires  some  explanation.  First,  if  a  group  of  processes  are  to  run  on  a  single 
resource,  together  they  can  only  execute  one  event  at  a  time.  If  two  events  are  simultaneously 
offered  from  communicating  partners,  one  must  be  rejected.  Thus  only  singleton  sets  can  have 
a  nonzero  priority.  Note  also  that  since  the  processes  are  assumed  to  be  consistent,  the  function 
P&(C)  is  well-defined. 

When  composing  two  truly  concurrent  systems  with  the  “||*’  operator,  the  priority  functions 
can  be  composed  as  follows:  7r(Pi||P2)  =  C'omposej|(7r(Pi),7r(P2)),  where 


VA  C  EVP  C  E,  Compose\\(pi,p2)(A,B)  =  pi(A,B)  A  p2(-4,P) 

Let  p.g  P(S)  x  P(S)  -+'BOOL  be  a  priority  function,  and  let  A  and  B  be  sets  of  events. 
For  convenience  we  use  the  following  notation: 

A  <p  B  iff  p(A,B ) 

A  =p  P  iff  A  <p  B  A  B  <p  A 
A  <p  B  iff  A  <p  B  A  P  A 

We  construct  our  semantics  to  exploit  this  ordering.  In  particular,  our  parallel  operator  guar¬ 
antees  that  if  there  is  a  choice  between  executing  A  and  P,  the  selection  is  made  by  this  priority 
ordering. 

X  ■  I 

4\8^'^Sfffd1!rj^t5oi¥rRecordsj  fffSEbries  and- Priorities  . 

F  j..  ■ 

Now  we  can  integrate  the  concepts  of  assumption  records  and  process  priorities.  Let  P  = 
(res, imp, exp, p, traces)  be  d,  process,  and  assume  that  (cr,h~(A,  A))  €  traces.  That  is.  h 
concatenated  with  the  record  (A,  A)  is  a  history  of  the  process’  behavior.  First,  by  the  con¬ 
struction  of  the  assumption  record,  V/l'  6  A,  A  <p  A'.  This  implies  that  for  every  A'  €  A. 
h'(A',A')  is  also  a  history  of  the  process,  where 


A7  =  {P  6  A  U  {A}  |  P  j*  A'  A  A'  <p  B). 
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Now  assume  that  A!  G  A,  with  A'  >p  A.  Thus  there  is  some  pair  { <r',h'‘(Al ,  A'))  in  traces. 
However,  it  cannot  be  said  that  the  events  in  A1  will  be  active  rather  than  those  in  A.  If  some 
event  is  used  for  communication,  another  participating  process  is  needed  for  synchronization. 
Thus,  only  when  all  of  the  communications  in  A1  are  resolved  can  we  say  that  A'  will  be  selected 
rather  than  A.  When  this  occurs  we  delete  the  history  h'(A,  A),  as  it  will  never  be  observed. 

To  formalize  this  concept,  once  a  processor  has  been  closed,  we  maintain  that  all  traces  are 
prioritized,  that  is:  V{cr,/i)  G  traces,  prioritized{p,  h, imp  U  exp),  where 

prioritized(p,h,B )  iff  Vi  <  \h\  VA'  G  MMi]),  /i(M*l)  <p  A!  ==$►  A'  n  B  ^  0 

In  other  words,  assume  that  h\\A,  A)  is  some  history  of  a  process  Pj.  If  there  is  a  set  A1  G  A 
with  A  <p  A',  we  guarantee  that  A'  contains  at  least  one  unresolved  event  from  Py's  alphabet. 
That  is,  in  order  for  all  the  events  in  A'  to  execute,  P\  must  be  composed  in  parallel  with 
some  other  process.  On  the  contrary,  assume  that  A'  contained  only  local  events.  In  this  case 
it  would  execute  instead  of  A,  and  thus  h\‘(A,  A)  would  not  be  a  history  of  Pi. 


5.9  The  Meaning  Function 

In  this  section  we  develop  a  meaning  function  “f  .J”,  which  maps  the  syntax  of  CSR  to  the 
domain  of  semantic  processes.  Often  we  make  use  of  the  partition  function,  defined  as  follows: 

partition(p,  A,  A)  =  (A,  {A'  G  A  U  {0}  |  A  ±  A'  A  A  <p  A'}) 

Here  A  may  contain  event  sets  with  lower  priority  than  that  of  A]  they  are  filtered  out  of  the 
record  returned  by  the  function.  We  note  here  that  0  represents  an  idling  behavior,  and  for 
any  priority  function  p,  0  has  the  lowest  priority  in  the  partial  order  defined  by  p. 


5.9.1  Wait 


The  wait  statement  specifies  an  idle  period  of  exactly  t  time  units,  where  t  >  1.  As  can  be 
seen  from  the  associated  priority  function  p,  idling  has  the  lowest  priority. 

l"  Ui  I  t 


5.9.2  Skip  F 


The  skip  statement  is  syntactic  sugar  for  wait  1;  thus  skip  requires  1  time  unit  to  execute: 

[skip]  =  [wait  lj 
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5.9.3  Write 

The  write  construct  declares  that  a  resource  is  ready  to  synchronize  on  an  exported  event.  The 
statement  delays  indefinitely  until  the  communication  is  successful,  that  is,  when  the  sending 
resource  issues  a  corresponding  “read”  event.  The  time  that  this  occurs  depends  on  1)  the 
priority  of  the  write  event  with  respect  to  other  events  competing  for  its  resource,  2)  the  time 
that  the  corresponding  read  event  becomes  ready,  and  3)  the  priority  of  the  read  event  with 
respect  to  other  events  competing  for  its  resource. 

fa!]  =  (0,0,  {a}, p, traces) 
where 

p  =  Compose &(0, 0,  {a}) 

traces  =  <{{T,(0,  {{a}})'‘parf itibn{p,  {a},  {0})}  |  i  >  0} 

The  first  part  of  the  history,  or  (0,  {{a}})‘,  denotes  that  after  a  becomes  ready,  there  may  be 
an  indefinite  idling  period  before  the  communication  is  successful.  But  the  presence  of  the  set 
{a}  shows  that  throughout  this  idling  period,  the  event  a  remains  ready.  The  second  part  of 
the  history  is  composed  of  a  single  assumption  record:  partition(p,  {a},  {0}),  which  represents 
the  success  of  the  communication.  This  record  can  have  two  possible  values,  depending  on 
the  priority  function.  If  PRI0(a )  >  0,  the  record’s  value  is  ((«},0),  while  if  PRI0(a)  =  0.  the 
record  be'-omes  ({a},{0}).  In  the  fi?st  case,  the  processor  cannot  arbitrarily  delay  itself  when 
.  the  matching  read  event  becomes  available.  In  the  second  case  delays  may  be  inserted,  which 
assigns  the  choice  to  communicate  exclusively  to  the  receiver. 

5.9.4  Read 

The  read  statement  is  the  exact  dual  of  its  write  counterpart  explained  in  section  5.9.3.  Here 
a  is  placed  in  the  import  alphabet;  the  write  statement  contains  a  in  its  export  alphabet.  Also, 
the  the  priority  value  for  a  is  taken  from  the  PRR  function. 

|a?J  =  (0,  {a},  0,p,  traces) 

V'f.  JcT'itraxrdcfylftfe.  •  I  mrJr;  '  ,-T > 

p  =  Compose^®,  {a},0)  f 

traces  =  <{(T,(0,  {{a}})l‘partition{p,  {a},  {0}))  |  i  >  0} 


5.9.5  Exec 

The  exec  statement  specifies  that  local  computation  events  must  compete  for  processor  time. 
The  exact  number  of  time  units  required  may  be  nondeterministic  -  thus  we  allow  a  range  of 
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time  units  to  be  specified.  Here,  m  is  the  lower  bound  on  the  number  of  executed  events,  and 
n  is  the  upper  bound.  It  is  assumed  that  1  <  m  <  n. 

[exee(a,  m,  n)J  =  ({a},  0,0,  p,  traces) 
where 

p  =  Composek({a},<b,$) 
traces  =  Uf=m  ^'({T,  A)) 
with 

P(X )  =C(<{(T,(0,{{a}});'Apartition(p,{a},{0}))|i  >  0},.Y) 

Note  that  .here  we  make  use  of  the  trace  composition  operator,  or  “C.”  In  effect  we  compose 
between  m  and  n  individual  executions  of  the  event  a,  and  we  include  all  of  the  “ready”  assump¬ 
tion  records  that  precede  each  execution.  Although  the  execution  time  of  a  does  not  depend  on 
any  communicating  partner,  it  heavily  depends  on  the  priorities  of  the  other  events  contesting 
for  processor  time.  To  make  the  interleaving  combinator  associative  (see  section  5.9.12),  we 
must  provide  the  possible  “gaps”  that  exist  between  each  local  execution.  They  may,  of  course, 
be  occupied  by  other  local  events  of  a  higher  priority.  Only  when  the  resource  is  closed  can 
the  unnecessary  gaps  be  eliminated. 

5.9.6  Guarded  Choice 

Our  guarded  choice  construct  is  priority-based  version  of  those  presented  in  [11]  and  [7].  Each 
of  the  guards  g ,•  may  be  one  of  the  following:  1)  a  read  guard,  “a?”,  2)  a  write  guard,  “a!”, 
or  3)  a  local  execution  guard,  “a”.  The  time  associated  with  the  wait  guard  is  assumed  to  be 
greater  than  0.  If  no  wait  guard  is  present,  we  assume  that  the  value  of  t  to  be  infinite.  As  iii 
related  languages,  the  execution  of  a  guard  gt  is  immediately  followed  by  that  of  Si. 

An  event-based  guard  must  be  executed  within  the  specified  t  time  units;  if  not,  Sn+l 
is  executed.  An  event-baced  guard  may  be  delayed  for  one  of  two  reasons.  In  the  case  of 
a  local  event,  there  may  be  contention  for  local  processor  time;  that  is,  interleaved,  higher- 
priority  events  are  given  the  “right  of  way.”  The  communicating  guards  also  suffer  from  local 

they  must  Itafbfor  their  corresponding  communicating  partners  to  be 
successfully  executed.  It  should  be  noted  tHat  these- partners  are  also  affected  by  the  local 
competition  on  their  processors.  Thus,  we  can  begin  to  see  one  of  the  ramifications  of  local 
competition  for  resources:  although  two  processes  may  be  willing  to  synchronize  at  a  given 
time,  actual  communication  may  be  delayed  due  to  local  resource  contention.  This  is  a  radical 
departure  from  the  “pure”  maximal  parallelism  model. 
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[[$*  ->  5iD . . .  Ogn  -+  Sn  A  wait  t  -*■  S'n+i]!  =  (res,  imp,  exp,  p,  traces), 
where 

r«  =  U?=t/KIs.l)UU'iV([5.J) 
imp  =  U?=1  ‘(bfl)  u  US;  i(KJ) 
exp  =  U?=i  <(M  U  US'  <(*» 

p  =  Composeu(res,  imp,  exp) 
traces  = 

<{(<?,  hi' h2'hz)\hi  £  W  A  jhi|  <  t  A  3i  <  n.(a,h3)  6  r([S;J)A 
h2  =  partition^ ,  aft#]),  {aflffiTj])  1 1  <  j  <  n})}  U 
<{(<?, hi' h2)\  hi  £W  A  \hi\  =  t  A  (cr,h2)  6  r([SB+i])} 
where 

W  =  m{a(lgi}),...,a(lgi])}r\i>0} 

Example  5.1  This  example  depicts  the  interaction  between  prioritized  events.  Here  a  and  b 
are  both  imported  communication  events,  with  PRIi(a)  —  1  and  PRI{(b)  =  2: 

S  =  [a? ^  a?] 

Informally,  the  semantics  for  5  can  be  explained  as:  “Wait  for  either  event  a  or  event  b  to  be 
received.  If  event  a  is  received  first,  accept  it  and  wait  for  b.  If  event  b  is  received  first,  accept 
it  and  wait  for  a.  If  both  events  are  received  simultaneously,  accept  event  b  and  wait  for  a." 
The  following  are  the  traces  of  S,  as  computed  by  the  definition  of  guarded  choice: 

<{(T,  (0,  {{a},  {&}})-({«},  {{&}})' (0,  0))  I  ij  >  0}  U 

<{<T,(0,{{a},{6}})-({6},0)'(0,{{a}}y“({a},0))|t,y  >  0} 

How  isj;he  priority  structure  reflected  in  the  histories  shown  here?  There  is  a  major  difference 
between  the  assumption  records  representing  the  two  communicating  guards.  The  record 
c\ eh 6Vifi ^u^rs^fl : m  a  n  ication  *wi  tTf  a  is  ({«},  {f^}  )')•  This  shows  that  if-event  b  is  received 
simultaneously  with  a,  the  processor  defers  to£,  and  the  histoVy  is  removed.  On  the  other  hand, 
the  record  representing  successful  communication  with  b  is  ({6},  0);  that  is,  no  alternative  of  a 
higher  priority  exists.  □ 

5.9.7  Sequential  Composition 

Sequential  composition  operates  in  the  usual  manner:  traces  from  S2  are  appended  to  com¬ 
pleted  traces  from  Si.  Fortunately  our  trace  composition  operator,  “C" ,  does  just  that;  thus. 
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the  definition  is  straightforward: 

[■ft;  Sal  -  (res, imp,  exp,p, traces) 
where 

res  =  p([ft]|)U  p([ft]),  imp  =  t([ftJ)U  exp  -  e([ft  j '  J  e(tftl), 

p  =  Composek(res,imp,exp) 
traces  =  C(r({5x]),r([52])) 

5.9.8  Within 

The  within  operator  denotes  that  5i  is  to  be  initiated  immediately,  and  that  it  must  be 
completed  within  the  specified  t  time  units.  If  ft  does  not  finish  executing  by  time  t ,  control 
is  transferred  directly  to  52.  Thus  ft  can  be  considered  a  timeout  exception  handler  of  sorts, 
which  is  an  essential  construct  in  many  real-time  programs. 

[within  t  do  Si  when  t  — *■  S2  od|  = 

(p([ft  ;  Sal).  *([$i ;  ftj),  <[ft ;  Sal),  *([ft  i  S2J),  traces) 
where  traces  = 

<{(T,h)\(T,h)  Gr([Sil)  A  |h|  <*}U 

<{(<?, hi* h2}\{±, hi)  €  t([SiJ)  A  (cr ,h2)  G  r([ftj)  A  |ft|  =  /} 

Example  5.2  As  an  example,  consider  the  following  fragment: 

S  =  within  10  do  a?; 6?  when  10  -*■  exec(c,  1,1)  od 

Here,  S  must  receive  events  a  and  b  within  10  time  units;  otherwise  it  will  attempt  to  execute 
the  local  event  c.  Thus  if  the  exception  handler  is  required,  we  can  reason  that  the  construct 
“a?;  6?”  did  not  complete  one,  or  both  of  the  communications.  This  can  be  seen  from  the 
traces  of  S  (where  we  assume  that  PRI{(a),  PRI,(b)  and  PRIi(c)  are  all  greater  than  0). 

‘<{(+,(0,  {{«}»•'-({<.},  .)-(#,  {{*}>y-({6>,0)>  1 ; + j  <  s}u 

S«T, (»,{{«}})*•({<•}, •)-(», {«})'-(«, <W})‘-(W,0))|i  +  i  =  9  A  *  >  0} 

□ 


5.9.9  Interrupt 

The  interrupt  operator  takes  full  advantage  of  our  priority  semantics,  and  we  have  found  it 
invaluable  in  our  specifications  of  robot-sensor  systems  [4].  The  construct  initiates  Si.  which 
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will  be  interrupted  only  if  1)  the  imported  event  a  is  detected,  and  2)  the  event  executing  in 
Si  has  a  lower  priority  than  PRI{(a).  If  both  of  these  conditions  are  met,  S\  is  immediately 
killed,  a  is  received,  and  control  is  transferred  to  the  interrupt-handler,  S2 •  This  is  not  the 
more  common  type  of  interrupt  construct,  where  control  would  be  transferred  back  to  S\  at 
the  conclusion  of  S 2.  Interrupt  handlers  of  that  nature  can  be  specified  using  the  interleave 
operator  (see  section  5.9.12). 

{interrupt  on  a  do  Si  when  a?  — ►  S2  odj  = 

(p(l'S'il)  Up(I52]),t([5il)  U  i({52])U  {a},e([5i])  U  e({S2]),p,  traces) 
where 

p  =  Composefe(/>(tSi]|)  U  pdS'sl), u  Kt^J)  U  {a}, <[£1 J)  U  e(|52D) 
traces  = 

<{(T 1 3(T,/i)  €  r({5i|)}U 

<{(£r2,/i'/i2)  |  (cr2,h2)  €  t‘([*S'21)  A  3(l,hY(A,  A))  Grd^il). 
h  —  I{h\Y partition(p,  {a},  {A}  U  A) 

where 

/(/*)  =  {/>' |  Vi  >13A3A. 

/i[i]  =  (A,  A)  A  h'[i]  =  partition(p,  A,  A  U  {{a}})}  - 

« 

»  -  * 

While  somewhat  complicated,  the  above  definition  for  traces  is  quite  easy  to  understand. 
First,  the  function  1(h)  constructs  a  new  history  from  h  in  the  following  manner.  For  every 
assumption  record  (A,  A)  in  h,  if  A  <p  {a}  then  {a}  is  inserted  into  A.  Otherwise  the  record 
remains  as  (A,  A).  Thus  1(h)  represents  when  h  may  be  interrupted  by  a.  So,  the  first  set  in 
the  traces  definition  contains  the  original  traces  of  Si,  plus  this  potential  interrupt  information. 

The  second  set  contains  the  traces  showing  where  S\  is  interrupted.  Each  trace  contains 
three  parts,  the  first  of  which  being  the  uninterrupted  part.  The  second  part  consists  of  single 
record,  depicting  the  time  at  which  S\  is  interrupted.  The  third  and  final  part  is  a  history 
from  theAnterrupt  handler,  52. 

5.9.10  Loop  P  f  - 

The  loop  construct  is  our  representation  of  general  recursion.  Its  continuity  is  contingent  on 
the  continuity  of  the  trace  composition  operator  “C,"  a  proof  for  which  can  be  found  in  [11]. 

{loop  do  S  odj  =  (p({51),t(|‘5'l),€({5l),7r({5'J),/:rflce.s) 

where  traces  =  U; 

with  P(X)  -  C(r([£J),X) 
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Example  5.3  As  an  example  of  loop  and  interrupt,  the  following  fragment  continuously 
executes  the  local  event  a,  while  waiting  to  be  interrupted  by  b,  at  which  time  c  is  locally 
executed. 

interrupt  on  b  do 
loop  do  exec(a,  1,1)  od 
when  bl  -*  exec(c,l,l)  od 

□ 


5.9.11  Every 

The  every  operator  is  used  to  specify  periodic  behaviors,  and  is  a  timed  variant  of  general 
recursion.  'Assume  that  for  in  a  given  case  S  requires  i  time  units  to  execute.  If  i  <  t  then 
S  runs  to  completion,  after  which  there  is  a  delay  of  t  -  i  units  before  the  body  is  restarted. 
On  the  other  hand,  if  i  >  t,  the  history  is  interrupted  after  t  time  units,  at  which  time  S  is 
immediately  reinitiated. 


[every  t  do  S  od]  =  (p([5]),i([5]|),€([5]),  1,jt([5]),  traces) 
where  traces  =  Ut>o 
with  P(X)  =  C(Y,X) 
where 

Y  =  <{{T ,h)  1 3(<7 ,h)  e  r{\S\wait  t]) .  |/i|  = 


5.9.12  Interleave  Operator 


The  interleave  operator  accepts  two  processes,  P\  and  ,  and  interleaves  their  histories  to 
execute  on  a  single  resource.  This  means  that  only  one  event,  either  from  P\  or  P-i ,  may 
be  executed  diving  a  single  time  period.  The  arbitration  between  the  two  processes  is  done 
according  to  the  priorities  of  the  events  ready  to  execute,  in  the  same  manner  as  guarded 
choice.  , 

A  vtt  »  < 

Note  the  first  line  of  the  definition,  where  the  composed  state  a  is  determined.  As  intuition 
wo'ulcfTi'^e'lf^t^^r^iSved  history  ^considered  coth^ldte  only  if  both  constituent  histories  are 
complete;  otherwise  it  is  considered  incomplete.  Alsd;  the  comparable  predicate  ensures  that 
if  two  incomplete  histories  are  composed,  they  must  be  of  equal  length.  If  only  one  history 
is  complete,  the  length  of  the  complete  history  cannot  exceed  that  of  the  incomplete  history. 
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These  rules  ensure  the  associativity  of  the  operator. 

[Pi&P2J  =  (p(IPt;  P2I,  t([Pi;  P2],  c([Pi;  P2],P,  traces) 
where 

P  =  7r([Pi;p2l) 
traces  = 

<{{a,h)\3(a1,hi)  G  rdP^^^,/^}  €  r(lP2]).(<r  =  ax  -  a2  =  T)  V  (cr  =  J_)  A 
comparable(ai,h\,C2,h2 )  A 

Vi  >  1  3A\,A2i  Ai,  A2  .  hi[i]  =  (Aj,  Aj)  A  /r-2 [ *]  =  (A2,  A2)  A 
(h[i]  =  partition(p,Ax,{A2}  U  Ai  U  A2)  V  h[i]  =  partition(p,  A2,  {A\}  U  Aj  U  A2))} 

where 

comparable((Ti,hi,cr2,h2 )  4=>  (<ti  =  1  =>  |h2|  <  |/ii|)  A  (cr2  =  1  =t>  |/ii |  <  |/i2|) 

Example  5.4  Now  we  can  specify  the  type  of  interrupt  handler  that  returns  to  an  interrupted 
program.  In  the  fragments  Pj  and  P2  we  assume  that 


PRIi(ax)  =  PP/,(a2)  =  PRIi(bi)  =  PRIi(h)  =  1,  and 
PP/,(a3)  =  PP/,(63)  =  2 


Pi  =  loop  do 

P2  =  loop  do 

[ai?  — ►  exec(&i,3, 10)  □  a2?  -*■  exec(&2,4,6)] 

[a3?  exec(63,5,5)] 

od 

od 

Now,  in  P1&P2  we  can  consider  exec(&3, 5, 5)  an  interrupt  service  routine,  executed  as  a  critical 
section  to  handle  the  interrupt  <z3.  After  the  interrupt  is  handled,  Pi  can  resume  execution 
until  another  interrupt  is  detected.  □ 


5.9.13*.  ..Close  Operator 

the  close  operator  ensures'”' that  a  program’s  resources  may  no  longer 
be  shared.'  This  implies  that  no  further  process  comhinators  may  be  applied  to  the  operand. 
In  particular,  the  predicate  “ prioritized ”  eliminates  all  time  “gaps”  that  were  being  preserved 
for  future  resource  sharing. 

|{5’}1  =  (p(^l)^(I‘5’l)!<f-5’!),7r(f5]]),  traces) 
where 

traces  =  <{(<r,h )  |  (cr,  /i)  G  rdS’P  A  prioritizedindSf),  h, i(lS])e({S]))} 
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Example  5.5  We  can  easily  illustrate  the  meaning  of  close  when  we  apply  it  to  the  statement 
S  in  example  5.2.  The  traces  of  {5}  are  now: 

<{<t,  (0,  {{«}})*“({«}, am  mm m,  0))  1  * + j  <  s>  u 

<{(T,(0,{{a}»loX{c},0))}U 

<{(T,(0,{{a}»-({a},  0r(0,  {{6}})^({c},0))  |  i  +  j  =  9} 

In  other  words,  we  no  longer  have  to  wait  for  the  execution  of  the  local  event  c.  Once  it 
becomes  ready,  it  can  be  immediately  executed.  □ 

5.9.14  Parallel  Operator 

Finally  we.  come  to  the  parallel  operator,  with  which  we  can  specify  true  concurrency.  Each  of 
the  operator’s  arguments  are  assumed  to  be  closed  processors  -  incapable  of  sharing  any  more  of 
their  resources.  At  this  point  they  interact  only  with  external  events.  Note  how  the  composed 
alphabet  is  formed.  All  external  events  through  which  the  two  processes  communicate  are 
resolved,  and  transformed  into  local  events.  At  this  point  they  can  are  considered  no  differently 
than  other  local  computation  events. 

The  state  resolution  is  identical  to  that  in  the  interleave  operator  -  a  resolved  trace  can 
be  considered  complete  only  if  both  contributing  traces  are  complete.  Also  like  the  inter¬ 
leave  operator,  the  comparable  predicate  is  used  to  ensure  consistency  of  history  length  (see 

section  5.9.12  for  its  definition). 

%  » 

If  two  histories  are  to  be  combined,  they  must  be  synchronized  on  the  events  through  which 
the  two  processes  communicate.  For  example,  assume  that  hi  G  rdPjl)  and  /?.2  G  r(fP2J). 
Also,  assume  that  some  event  a  is  imported  by  Pi  and  exported  by  P2.  If  there  is  some  i  such 
that  a  G  /i(^i[*D  but  a  g  /i(^2[i])j  these  two  histories  cannot  be  composed.  This  is  because 
at  time  i,  Pi  is  ready  to  communicate,  while  P2  is  not. 

[Pi||P2]  =  (res, imp,  exp,  p,  traces) 
where 

^  =  p([Pil)  u  p(fP2J)  u  ddPi])  n  C([P2J))  u  (e(|[PiJ)  n  t(lP2|)) 
e([P2J))  U  (*&&])  - 

exp  =  (€(|PiJ)  -  4([P2]))  U  («([/y)  -  F([Pi!))--  * 

p  =  C'ompose||(7r(P1),7r(P2)) 
traces  — 

<  {{<?>  h)  1 3(<J\  ,h{)  G  r(tPiJ)  3 (<r2,  h2)  G  r(|P23) .  (cr  =  a  =  a2  =  T)  V  (o  =  JL)  A 
comparable(cr i ,  Ai ,  cr2 ,  /j2)  A  (Vi  >  lsync(fi(hi[i}),  fi(h2[i])))  A 
(Vi  >  1  A[ij  =  combine(hi[i),h2[i)))  A  prioritized(p,  h,  imp  U  exp)} 
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where 

sync(AlfA2)  4=*-  Va  6  ((if-Pi]  H  c[P2]|)  U  (€[Pi]  n  (a  G  Aj  <s>  a  e  A2) 

com&me((Ai,Ai),(A2,  A2))  = 

(Ai  U  A2, 

{A'x  U  A2  |  sync(A'1 ,  A!2 )  A 

((A^  G  Ai  A  j4'2  6  ({ A2}  U  A2))  V  (A4  €  A2  A  A\  6  ({A*}  U  Ai)))}) 

Example  5.6  Now  we  can  complete  example  5.1.  Let  P  =  {5},  or 

P  =  {[a?  -«□&?-  a?]} 

and 

q  —  {«!}  R=m 

Assume  that  PRI0(a )  =  PRI0(b)  =  0;  that  is,  we  give  the  resource  P  the  exclusive  right  to 
choose  when  the  communication  occurs.  It  follows  that: 

<[Q  1)  =  <{<T,(0,{{a!}»-({«},{0»)  |f  >  0} 
r(M  =  <{<T ,  (0,  {{&!}})* ~({6},  {0})}  |  i  >  0} 

and  that 

r(lP\\Q\\R])  =  <{{T,  ({6},  {0})'({a},  {0}))}  *  ’ 

Since  PRIi(b)  >  PRIi(a),  this  is  exactly  what  we  would  expect.  □ 


6  Conclusion 

In  this  paper  we  have  presented  a  real-time  specification  language  called  CSR.  This  formalism 
can  be  considered  as  a  step  toward  unifying  real-time  specifications  with  their  corresponding 
implementations.  The  CSR  paradigm  imposes  that  specifications  be  resource-based ;  a  process 

as  resident  on  a  particular  resource.  Moreover,  this  resource  may 
have  showifln  our  robot-censor  example  (sectkur.4).  Thus  we  have 
departed  from  the  “pure”  maximum  parallelism  mocfel,  which  assumes  a  one-to-one  allocation 
of  processors  to  processes.  To  arbitrate  between  processes  competing  for  a  single  resource, 
we  have  incorporated  a  general,  event-based  priority  scheme.  With  prioritized  events  we  can 
model  not  only  Occam's  PRI  ALT  and  PRI  PAR  constructs,  but  more  versatile  systems,  in 
which  processes  continuously  alter  their  priorities  over  time. 

CSR  can  specify,  and  give  precise  meaning  to  some  behaviors  necessary  in  modern  real¬ 
time  systems.  For  example,  the  within  statement,  with  its  associated  exception-handler,  can 


must  explicitly  be  declared 
hos  t oThejT  processes^*  as  we 
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specify  a  temporal  scope  as  described  in  [12].  The  every  statement  accurately  captures  the 
behavior  of  a  periodic  process.  The  two  interrupt-handling  mechanisms  -  one  that  returns 
to  an  interrupted  program,  the  other  that  kills  it  -  can  help  denote  the  relative  criticality 
of  received  events.  To  formalize  all  of  our  constructs,  we  have  provided  set  of  denotational 
semantics  that  captures  both  CSR’s  interleaved  resource-sharing,  and  the  “pure”  concurrency 
that  occurs  between  resources. 

Much  future  work  remains  to  be  performed.  To  facilitate  automated  reasoning  about 
CSR,  we  wish  to  provide  it  with  an  operational  semantics,  fully  abstract  with  respect  to  the 
denotational  semantics  presented  here.  We  plan  to  do  this  with  a  labeled  transition  system, 
in  the  spirit  of  [7].  However,  we  are  not  yet  certain  how  its  complexity  will  be  affected  by  our 
interleaved,  priority-based  model. 

Also,  we  are  currently  investigating  whether  the  CSR  formalism  can  be  mapped  to  a  system 
of  communicating,  finite-state  machines.  This  technique  has  been  explored  for  the  “pure” 
maximum  parallelism  model  [14],  but  again,  we  are  unsure  how  the  additional  complexity  of 
CSR  will  affect  such  an  endeavor.  However,  if  some  variant  of  CSR  can  be  mapped  to  finite- 
state  machines,  state  exploration  techniques  can  be  used  to  statically  detect  properties  such 
as  liveness  and  deadlock. 

Finally,  we  are  extending  the  CSR  formalism  to  permit  the  specification  of  dynamic  priority 
schemes.  The  current  model  is  quite  powerful,  in  that  processes  can  continuously  alter  their 
own  priorities  over  time.  However,  the  main  thrust  of  our  research  is  directed  toward  analyzing 
scheduling  behavior.  A  scheduler  has  the  ability  to  dynamically  alter  the  priorities  of  other 
processes,  based  on  the  state  of  the  system.  Thus,  we  are  currently  incorporating  the  semantics 
of  variable  states  into  CSR.  With  this  inclusion  we  will  be  able  to  reason  about  dynamic 
priorities,  and  therefore,  about  the  properties  of  real-time  scheduling  algorithms. 
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